fix(server): preserve Kubernetes sandbox security - #1506

What changed

• preserve template-owned container security contexts and resource limits when Kubernetes runtime values add or update named pod objects
• round-trip runAsNonRoot and runAsUser through the server's Kubernetes security-context helpers
• keep the egress init and sidecar root requirements explicit and container-scoped
• move the server runtime to Alpine and remove unused system setuptools packages from the production image

Why

The generic list replacement in the Kubernetes template merge replaced the template sandbox container with the runtime container. That silently discarded template-owned capability drops, allowPrivilegeEscalation, and resource settings. Separately, a pod-level non-root identity overrode the egress init/sidecar requirements, preventing IPv6/nftables setup.

The name-aware merge follows Kubernetes' merge-key convention while leaving unnamed lists such as commands and tolerations replace-only. No API or CRD shape changes.

Validation

• uv run pytest tests/k8s/test_batchsandbox_provider.py tests/k8s/test_batchsandbox_template.py tests/k8s/test_egress_helper.py -q — 180 passed
• focused Ruff and Pyright checks — passed
• native linux/arm64 server image build — passed
• built image opensandbox-server --help smoke — passed
• downstream k3d validation created a uid-1000 sandbox with RuntimeDefault seccomp, all capabilities dropped, no privilege escalation, retained resource limits, and working egress